The Margin property is defined by FrameworkElement; in real-life Silverlight programming, almost everything gets a non-zero Margin property to prevent the elements from being jammed up against each other. The Padding property is rarer; it’s defined only by TextBlock, Border, and Control.
It’s possible to use Margin to position multiple elements within a single-cell Grid. It’s not common—and there are better ways to do the job—but it is possible.
What’s crucial to realize is what we’re not doing. We’re not explicitly setting the Width and Height of the TextBlock like in some antique programming environment:
<TextBlock Text="Top-Left"
VerticalAlignment="Top"
HorizontalAlignment="Left"
Width="100"
Height="50" />
You’re second guessing the size of the TextBlock without knowing as much about the element as the TextBlock itself. In some cases, setting Width and Height is appropriate, but not here.
The Width and Height properties are of type double, and the default values are those special floating-point values called Not a Number or NaN. If you need to get the actual width and height of an element as it’s rendered on the screen, access the properties named ActualWidth and ActualHeight instead. (But watch out: These values will have non-zero values only when the element has been rendered on the screen.)
Some useful events are also available for obtaining information involving element sizes. The Loaded event is fired when visuals are first arranged on the screen; SizeChanged is supported by elements to indicate when they’ve changed size; LayoutUpdated is useful when you want notification that a layout cycle has occurred, such as occurs when orientation changes.
The SilverlightWhatSize project demonstrates the use of the SizeChanged
method by displaying the sizes of several elements in the standard
page. It’s not often that you need these precise sizes, but they might
be of interest occasionally.
You can associate a particular
event with an event handler right in XAML, but the actual event handler
must be implemented in code. When you type an event name in XAML (such as SizeChanged) Visual Studio will offer to create an event handler for you. That’s what I did with the SizeChanged event for the content grid:
Example 2. SilverlightProject: SilverlightWhatSize File: MainPage.xaml (excerpt)
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0"
SizeChanged="ContentPanel_SizeChanged">
<TextBlock Name="txtblk"
HorizontalAlignment="Center"
VerticalAlignment="Center" />
</Grid>
|
I also assigned the TextBlock property Name to “txtblk.” The Name
property plays a very special role in Silverlight. If you compile the
program at this point and look inside MainPage.g.cs—the code file that
the compiler generates based on the MainPage.xaml file—you’ll see a
bunch of fields in the MainPage class, among them a field named txtblk of type TextBlock:
internal System.Windows.Controls.TextBlock txtblk;
You’ll also notice that this field is assigned from code in the InitializeComponent method:
this.txtblk = ((System.Windows.Controls.TextBlock)(this.FindName("txtblk")));
This means that anytime after the constructor in MainPage.xaml.cs calls InitializeComponent, any code in the MainPage class can reference that TextBlock element in the XAML file using the txtblk variable stored as a field in the class.
You’ll notice that several of the elements in the MainPage.xaml file are assigned names with x:Name rather than Name. As used in XAML, these two attributes are basically equivalent. Name only works with elements (that is, instances of classes that derive from FrameworkElement because that’s where the Name property is defined) but x:Name works with everything.
This means that code in the MainPage class in MainPage.xaml.cs has a field available named ContentPanel to reference the standard Grid that appears in MainPage.xaml, and similarly for the other elements in MainPage.xaml.
Assigning names to
elements is one of two primary ways in which code and XAML interact. The
second way is for the element defined in XAML to fire an event that is
handled in code. Here’s the handler for the SizeChanged event of the content grid as Visual Studio created it:
Example 3. SilverlightProject: SilverlightWhatSize File: MainPage.xaml.cs (excerpt)
private void ContentPanel_SizeChanged(object sender, SizeChangedEventArgs e)
{
}
|
I usually don’t like the way Visual Studio creates these handlers. Normally I remove the keyword private, I rename the event handlers to start them with the word On, and I eliminate underscores. This one I’d call OnContentPanelSizeChanged. I also tend to change the event arguments from e to args.
But for this program I’ll leave it as is. On entry to the method, the sender argument is the element that fired the event, in this case the Grid named ContentPanel. The second argument contains information specific to the event.
I added a body to this method that just sets the Text property of txtblk to a longish multi-line string:
Example 4. SilverlightProject: SilverlightWhatSize File: MainPage.xaml.cs (excerpt)
private void ContentPanel_SizeChanged(object sender, SizeChangedEventArgs e)
{
txtblk.Text = String.Format("ContentPanel size: {0}\n" +
"TitlePanel size: {1}\n" +
"LayoutRoot size: {2}\n" +
"MainPage size: {3}\n" +
"Frame size: {4}",
e.NewSize,
new Size(TitlePanel.ActualWidth, TitlePanel.
ActualHeight),
new Size(LayoutRoot.ActualWidth, LayoutRoot.
ActualHeight),
new Size(this.ActualWidth, this.ActualHeight),
Application.Current.RootVisual.RenderSize);
}
|
The five items are of type Size, a structure with Width and Height properties. The size of the ContentPanel itself is available from the NewSize property of the event arguments. For the next three, I used the ActualWidth and ActualHeight properties.
Notice the last item. The static property Application.Current returns the Application object associated with the current process. This is the App object created by the program. It has a property named RootVisual that references the frame, but the property is defined to be of type UIElement. The ActualWidth and ActualHeight properties are defined by FrameworkElement, the class that derives from UIElement. Rather than casting, I chose to use a property of type Size that UIElement defines.
The first SizeChanged event occurs when the page is created and laid out, that is, when the content grid changes size from 0 to a finite value:
The 32-pixel difference between the MainPage
size and the frame size accommodates the system tray at the top. You
can prevent that tray from appearing while your application is running
(and in effect, get access to the entire screen) by changing an attribute in the root element of MainPage.xaml from:
shell:SystemTray.IsVisible="True"
to
shell:SystemTray.IsVisible="False"
The syntax of this attribute might seem a little peculiar. SystemTray is a class in the Microsoft.Phone.Shell namespace and IsVisible is a property of that class, and both the class and property appear together because it’s a special kind of property called an attached property.
The topmost Grid named LayoutRoot is the same size as MainPage. The vertical size of the TitlePanel (containing the two titles) and the vertical size of ContentPanelLayoutRoot because of the 45-pixel vertical margin (17 pixels on the top and 28 pixels on the bottom) of the TitlePanel. don’t add up to the vertical size of
Subsequent SizeChanged events occur when something in the visual tree causes a size change, or when the phone changes orientation:
Notice that the frame doesn’t change orientation. In the landscape view, the system tray takes away 72 pixels of width from MainPage.
